システム開発のジレンマ – ソフトウェア産業の重層的下請構造：イノベーションと生産性に関する実証分析 (経済産業研究所より)
モモンガー！
はい、最近みんなが僕の専売特許である
｢がおー｣とか「ぴかー」を多用するのであらたに、「モモンガー！」
を使い始めようと思います。
さて、昨日のことを少し書くと、
ものすごいでっかい魚を580円で購入し、
それをさばいてから渋谷に行きました。
そこで、上海に留学してたり、インドにいったりNYにいったりと
何かいろんなことをやっている方と3時間ぐらい話したのかな、
ま、面白かった。
その後バスに乗って帰ろうと思ったら、間違って変なところに降ろされて、
何とか渋谷まで戻って会社の寝袋で寝ることにしました。
ベトナムからラオスへ向かうバスで、
目的地に朝到着するはずが、夜中に路上で突如降ろされて、
金を請求してきたので僕がものすごく怒ったら、必死に3人ほどで
なだめてきて翌日目的地まで俺を連れていくという約束をさせて、
結果、観光客も誰もいない変な漁村で降ろされたことを考えると、
全然大した経験ではないですね。
ほんと先進国の精神の荒廃と軟弱さは自分を含めて辟易してしまいます。
さて、話がそれたので戻す。
本日はちなみに何をするかというと、 友人の知人の方と会うことになっています。
その合間に、お仕事をしておきます。
さて、このまま終わったら、また顰蹙の嵐かと思うので、
ざっくりと表題に近いことを書いておく。(あまり期待はなしで。)
ふと、会社の印刷のところで一枚面白い紙を発見した。
そこで、簡単に下記のようなのが絵付きで書かれていた。
すごくわかりやすかったが、ネット検索で発見できなかったので
テキスト文字のみで記載しておく。
こっから下はめちゃくちゃおもんない話になるので、
僕の中高時代の友人知人はここまで読んでくれたらOKです。
なんか仕事的なところをネタにした話などがよいというのであれば、
ぜひ下のところも読んでもらえればと思います。
※ブログにはもう少しきちんと書いてるけど、
mixiカスタマイズはしています。
———————————————
■システム開発のジレンマ
———————————————
１．顧客が説明した要件
２．プロジェクトリーダの理解
３．アナリストのデザイン
４．プログラマのコード
５．営業の表現、約束、
６．プロジェクトの書類
７．実装された運用
８．顧客への請求金額
９．得られたサポート
１０．顧客が本当に必要だったもの
自分なりに解釈してみますと、
———————————————
■システム開発のジレンマ
———————————————
１．顧客が説明した要件
はい、顧客は時にというかほぼ要件定義はあいまいです。
理想的なソリューションを伝えてはくれるのですが、
それに至るまでの細かい実装のあたりの仕様までは、期待できず、
言われた通りにしているだけでは、プロとは言えません。
２．プロジェクトリーダの理解
顧客からの要件を企画営業がまとめて、実際のPMに伝えるが、
その時の設計者の理解に乖離があると、もちろんうまくいきません。
３．アナリストのデザイン
うーん、これの意図するところはよくわからないので保留。
４．プログラマのコード
はい、実際のプログラムコードをどう記述していくか、
これも重要な問題になります。
たとえば、ブラウザ環境での変化及び修正/削除などをした場合の
ページ遷移の細かいクオリティアップなどなど、
やりだすときりがないぐらいですね。
５．営業の表現、約束、
はい、これも超重要です。
営業は、｢できる｣「できない」という二大判断の伝達のみならず、
時期及び工数（お金）によってどうか、という曖昧な手段もあったりします。
基本的に案件のロストはしない方向で動きたいという本能があるので、
動ける感じには伝えておいたりしますが、それも社内調整や
実際の期限と予算内で行けるかどうかはまた別問題になります。
どれだけ、お客さまに適切に説明し、「にぎって」おくかが重要です。口頭ではなく、メールベース及び案件が百万以上のクラスになれば、別途一筆交わしておく方がベターでしょう。
６．プロジェクトの書類
実装及び二時開発等までのマイルストーン等のことなのか、
実際のページ遷移などを含めた外設<外部設計書>とかのことかなー、
うーん保留。
７．実装された運用
はい、「これでできたよー」ってもっていくと、
結構相手によって印象が違っていたりします。
もちろん同じことを考え同じ仕様で進めているのにもかかわらずです。
ま、このあたりはコミュニケーションやな(笑)
８．顧客への請求金額
はい、実際にいつイニシャルが振り込まれ、ランニング費用がどうか、というのはさておき、結構二次開発をするかどうかというのも、
リリース及びその一ヶ月間での状況を見て決めるとかいう変なやつも、
<ある意味合理的ですが>あったりします。
デモ、基本的にはほんとの社内工数や外注コストなどを考えると、
めちゃくちゃ厳しいのに、請求金額はFIXしたものというのは、
案件としては、大失敗です。
しかしながら、デスマーチっぽくなったときの失敗の着地も
きちんと計算し設計し次のビジネスに行かなければいけないのが、
プロです。
９．得られたサポート
これもいろんな意味があります。
社内的なサポート、お客さん~のフォロー情報の提供など
うーんよくわからないので保留。
１０．顧客が本当に必要だったもの
はい、これが重要です。
お客さんがイメージしている理想、ソリューションがあるわけで、
しかしながらそれらは内包されていて具現化されていないケースがほとんど。
それらをどれだけ、表に出させてしかも、お客様自身で きっちりと認識させられるか、
それらをどうお互いに定量的に、 マイルストーンも明示して、
担当や期限などなどまで共有できるか、 というのがプロジェクト成功のポイントになるのかなーとか思います。
ま、下記のところなどもある程度参考になるのでつけておく。
■ソフトウェア産業の重層的下請構造：イノベーションと生産性に関する実証分析
DPDL(ディスカッションぺーパーのダウンロード)
http://www.rieti.go.jp/jp/publications/dp/09j002.pdf
峰滝和典 (関西大学ソシオネットワーク戦略研究機講)
元橋 一之 (ファカルティフェロー)
著者紹介：http://www.rieti.go.jp/users/motohashi-kazuyuki/index.html
このページも実際のプロジェクト成功の割合など書いてたので、
載せておく。<日本のケースじゃないけどね。だけど日本語だよ>
http://www.rieti.go.jp/it/column/column040326.html
———————————————
■要旨まとめ
———————————————
<ソフトウェア開発は失敗の歴史>
・企業におけるソフトウェアの開発・導入を数百例調査した結果によると、ソフトウェアプロジェクトの6つの内5つは失敗と見なされている。
・また約1/3のプロジェクトが途中で中止されている。
・残る2/3のプロジェクトは、予算の倍の経費を投じ、予定の倍の時間を費やして、やっとのことでソフトウェアを完成させている
・国防総省の報告書によれば、1999年の米国の官民合わせたソフトウェア開発プロジェクトのうち、31%が途中でキャンセル、51%において予算とスケジュールがオーバー、その上完成品の61%については顧客の初期要求を満たしていないという結果が出ている。
・生産性・品質格差の拡大と、入札時における情報の非対称性
⇒これは確かに言えますね。
官公庁へのシステム取引の場合は、全て基本は入札になる。
その際のシステム定義の言葉の定義などもどういう意味なのか、
きっちりと確認する必要がありそのあたりのノウハウも、
かなり重要なナレッジとなり得ているが、通常であれば、
実績のない企業が参入するのはかなり障壁となっていると思う。
最初は大変やったよ。
<オープンソース利用によるシステム開発及び営業>についても、
また時間があれば書く。
おわり。
がおー。
